Firstly, the abbreviations mainly involved in this document are defined as follows.
HSS: Home Subscriber Server;
OSA: Open Service Architecture;
IMS: IP Multimedia Subsystem;
SIP: Session Initiation Protocol;
AS: Application Server;
UE: User Equipment;
ISC: IP multimedia Service Control;
SCS: Server Capability Server;
SCIM: Service Capability Interaction Manager;
CAMEL: Customized Applications for Mobile network Enhanced Logic;
CAP: CAMEL Application Part;
MAP: Mobile Application Part;
IM-SSF: IP Multimedia Service Switching Function;
P-CSCF: Proxy Call Session Control Function;
S-CSCF: Serving Call Session Control Function;
Sh: Communication Reference Point between HSS and AS;
Si: Communication Reference Point between HSS and CAMEL AS (IM-SSF);
Cx: Communication Reference Point between HSS and CSCF.
IP Multimedia Subsystem (IMS), as the core technology of the next generation network, provides a universal service enabling platform for future multimedia application with functions of service control, safety function such as authentication and authorization, charging, routing, registration, sip compression and Qos supporting etc. IMS is independent from access network, and IMS terminals support SIP protocol. IMS terminals are featured in high intelligence and easy implementation of service development. Furthermore, IMS, supported by packet-switched network, has one great advantage of supporting data service.
Based on the principle of separating service from control in next generation network, IMS provides, in its service layer, an open interface to access various service servers so that various service providers can provide their respective services to network through a standard interface. Correspondingly, service can be loosely coupled to lower layer of network; this brings a rapid and flexible service development environment. A service framework of IMS is shown in FIG. 1. The framework, as shown in FIG. 1, is composed of an S-CSCF and various application servers connected to the S-CSCF through various internal service control interfaces based on SIP. 3GPP criterion provides three kinds of service structures:
1) SIP application server;
2) OSA service capability server;
3) Service application based on CAMEL (IM-SSF, IM service switching function).
Normally, when a calling party initiates a call to a called party, if the called party has stated his desire to avoid to be called by subscribing services such as call transfer, absent subscriber service, no disturbance, extension call limit, call forwarding etc., call application server and call control network element will not connect the call, initiated by the calling party, to the called party. Contrary to the above, emergency call override service is such that, if a calling terminal, with right of emergency call override, calls a called party by the approach of using emergency call override accessing code, the call application server and call control network element will execute emergency call override service and directly connect the call to the called party.
Traditionally, emergency call override service is implemented in Circuit Switch (CS) domain. In this meaning, emergency call override service is an IP Centrex service under soft switch network.
As shown in FIG. 2, the implementation process of emergency call override service in current soft switch architecture mainly comprises the following steps:
S201, a calling party terminal A calls a called party terminal B, by dialling in manner of emergency call override. Users A, B belong to a same soft switch, and the dialling manner is dialling service access code plus called number. The service code is a special identifier set by IP Centrex and configured on soft switch, and used for representing emergency call override service.
S202, the soft switch executes the following service processes after receiving an initial invite request: determining that the call is an inter-domain call and does not need cross-domain; analyzing the service access code; determining it as an emergency call override service; analyzing the service limitation of calling party; if the calling party terminal A has a call override right, then connecting the call to called party terminal B.
S203, the soft switch sends the initial invite request to user terminal B after executing service process.
But, a method for implementing emergency call override service is not disclosed currently in the IMS network architecture.
In the IMS network architecture, the call process is different from that under the soft switch architecture; and the process shown in FIG. 2 cannot implement the emergency call override in IMS network architecture.
Specifically, the S-CSCF executes a session control function in IMS network architecture; SIP AS, as an application server, is used for finishing service logic operation of multimedia voice and supplementary service of a user. As for a multimedia voice call, the S-CSCF triggers SIP AS through iFc triggering mechanism so as to implement specific service. As for a complete call, the S-CSCF needs to trigger the SIP AS for two times; wherein one is used for triggering an AS on the calling side; and the AS on the calling side finishes the calling side service logic; the other one is used for triggering an AS on the called side; and the AS on the called side finishes the called side service logic. As shown in Step 303 in FIG. 3, when the AS on the calling side finishes calling service logic, the AS on the calling side returns the initial INVITE request for establishing a call to S-CSCF. Then service access code information in called number is deleted, because that the AS on the calling side needs to convert the called number into global routable SIP URI or TEL URI, for the global routing of S-CSCF according to called number; thus, the AS on the calling side cannot transmit the service override right of the calling party to the AS on the called side. As shown in Step 305 in FIG. 3, when the AS on the called side receives the triggering of S-CSCF, it cannot determine whether the calling party has an emergency call override right and whether the call initiated by the calling party requires emergency call override; then the service logics of no disturbance or call forwarding services of called party are executed, thus the call override function is not implemented.
As shown in FIG. 3, the specific triggering process of basic call service in IMS network architecture is as follows:
S301, user UE sends a SIP initial INVITE request to its home S-CSCF and starts a SIP session.
S302, after receiving the request, the S-CSCF on the calling side deduces a service profile trigger (SPT) from the request and checks whether the SPT matches a filter criterion X; if matches, then the S-CSCF forwards the request to home AS1 of the calling party.
S303, the AS1 executes specific service logic according to ServiceKey subscribed by calling party, and sends the SIP request back to the S-CSCF on the calling side after the execution; and the service related information may be modified.
S304, the S-CSCF on the calling side searches for home S-CSCF of the called party after receiving the SIP request from AS1 and forwards the request to the S-CSCF on the called side.
S305, after receiving the request, the S-CSCF on the called side deduces SPT from the request and checks whether the SPT matches a filter criterion Y; if matches, the S-CSCF on the called side forwards the request to home AS2 of the called party.
S306, the AS2 executes specific service logic according to ServiceKey subscribed by called party, and sends the SIP request back to the S-CSCF on the called side after the execution; and the service related information may be modified.
S307, the S-CSCF on the called side checks the SIP request sent by AS2 and determines that the request does not match with any filter criterion; then the S-CSCF on the called side searches for a next hop according to normal SIP routing mechanism and forwards the request.
Based on above mentioned description, the emergency call override service in IMS network architecture cannot be implemented currently.